The Harmful Impact of Estimations on Agility

In my previous post 10 Reasons Why Estimations Are Harmful in Software Development, I shared several reasons why I believe estimations are detrimental to software development. Now, I'd like to delve deeper into how estimations negatively impact agility.

📅 Sticking to the Plan 📊
Estimations typically form the foundation of plans, whether long-term release plans or short-term scopes like Scrum Sprints. There's an implicit reward in adhering to the plan, often disregarding changes or learning opportunities along the way. The plan has already been created—any change requires additional effort. The plan is tied to a due date—nobody wants to deliver "late," so they stick to the plan. This natural behavior contradicts the agile value of "Responding to change over following a plan." (Note: The Agile Manifesto values the items on the left more than those on the right.)

🔝 Misguided Prioritization 🔝
Let's use Sprint Planning as an example. The duration of a Sprint is fixed, so we juggle the scope to fit the time box. We estimate using time or complexity. To avoid "idling" within the sprint, we fill the scope with stories and other smaller tasks that fit the timeframe. Consequently, we're not prioritizing and delivering the most important value for the customer, but rather fitting in arbitrary tasks that match the timeframe. This violates the agile principle: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." By the way, this is the main reason I prefer Kanban to Scrum.

🧠 Test and Learn 🧠
A proper test-and-learn approach to optimize user value, including pivoting the solution, becomes challenging with estimations—unless you constantly re-estimate. This violates the agile principle: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

💸 Product Debt and Technical Debt 💸
Typically, when estimations are made, knowledge about what needs to be done and potential time-consuming issues is limited. To meet the due date derived from the estimation, people often take shortcuts. As a result, the quality, extensibility, and usability of the solution suffer—but at least the plan was followed and the due date was met - almost. This violates the agile principle: "Continuous attention to technical excellence and good design enhances agility."

📝 Incorrect Measurement of Progress 📝
With estimations and their resulting plans, the primary measure of progress shifts from software and delivered value to a date. Projects are typically labeled as "late" or "on time." This violates the agile principle: "Working software is the primary measure of progress."

But does this mean we are not agile, as soon as we do estimations?

Let's discuss!

Please let's discuss on LinkedIn.